Date: Tue, 28 Jun 94 04:30:01 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #132 To: tcp-group-digest TCP-Group Digest Tue, 28 Jun 94 Volume 94 : Issue 132 Today's Topics: History and the Final TNC Router Project (7 msgs) TCP-Group Digest V94 #130 Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 27 Jun 1994 10:14:40 -0700 From: jackb@mdd.comm.mot.com (Jack Brindle) Subject: History and the Final TNC To: tcp-group@ucsd.edu Phil Karn says... >>> It's no wonder that some of those contributors have disappeared from >>> the list > >>Most of them graduated and went to work... > >Or changed jobs and started doing this stuff for real... And that's the truth. Many of the people doing CDPD development are escapees from the ham tcp/ip packet radio world. At the moment, CDPD appears to be the closest "real" (no arguments please) commercial system to what we hams are really wanting (and trying) to do. Of course, one could argue that the ham involvement is why it looks this way ;-). Jack Brindle ------------------------------------------------------------------------------ ham radio: wa4fib internet: jackb@mdd.comm.mot.com ------------------------------ Date: Mon, 27 Jun 1994 06:25:26 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Router Project To: tcp-group@UCSD.EDU > Linux gets 56Kbit with no losses on a 386DX40 with SCSI disks, 38400 with IDE > due to certain IDE drives needing you to lock interrupts off during a transfer > to avoid nasty messes occuring. The code is clean and could as equally be > shoved into DOS or anything else. Another way to attack this from the > NOS/DOS side is to use the FOSSIL drivers. That's not what I meant actually. I run 38400 all day long on my Procomm for Windows (to a 14.4 modem) and it works fine. The problem is purely the NOS implementation. If you put NOS on Linux it would be a dog compared to the Linux I/O. FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as the block of data would still have to go through the SLIP/KISS routines which operate at one character at a time. What would fix it probably is routines which pushed one Frame at a time after being processed in the background. But I don't care enough to fix it, as Ethernet cards cost the same as serial cards and performance is so much better. I've been running a different version of PD Unix, but the user base never developed. It's frozen at about the 1991 level :-) Guess I need to switch to Linux. What's a good internet source for the latest? -- Steve ------------------------------ Date: Mon, 27 Jun 94 10:50:42 EST From: "Ashok Aiyar" Subject: Router Project To: ssampson@sabea-oc.af.mil On Mon, 27 Jun 1994 06:25:26 -0500 (CDT), Steve Sampson wrote: > >I've been running a different version of PD Unix, but the user base never >developed. It's frozen at about the 1991 level :-) Guess I need to switch >to Linux. What's a good internet source for the latest? > I recommend the Slackware distribution over any of the others. The home site is ftp.cdrom.com, but it is also available from tsx-11.mit.edu, and perhaps sunsite.unc.edu Cheers, Ashok (lurker who wishes he knew enough to contribute more often) -- Ashok Aiyar ashok@biochemistry.cwru.edu Department of Biochemistry Tel: (216) 368-3300 CWRU School of Medicine Fax: (216) 368-4544 ------------------------------ Date: Mon, 27 Jun 94 09:39:55 -0500 From: sbrown@charon.dseg.ti.com (Steve Brown) Subject: Router Project To: ssampson@sabea-oc.af.mil Steve Sampson writes: > I've been running a different version of PD Unix, but the user base never > developed. It's frozen at about the 1991 level :-) Guess I need to switch > to Linux. What's a good internet source for the latest? The home of the Linux stuff is sunsite.unc.edu in the /pub/Linux directory. IMHO, the really slick way to deal with Linux is to get one of the CD-ROM distributions. The most recent ones allow you to mount the CD-ROM device and leave a lot of the stuff that you may need only occasionally on the CD-ROM. I have personal experience only with the Trans-Ameritech version. There are several others. The disk is about $30, if memory serves. Can't touch it for $5000 in the commercial world. Standard disclaimer about being a customer, etc., applies. Your mileage may vary. 73 es GL, ********************************************* | Steve Brown, WD5HCY | | | sbrown@charon.dseg.ti.com | Simplicate | | wd5hcy@wd5hcy.ampr.org | and add | | [44.28.0.61] | lightness. | | wd5hcy@kf5mg.#dfw.tx.usa.na | | ********************************************* ------------------------------ Date: Mon, 27 Jun 1994 12:20:25 -0400 From: "Brandon S. Allbery" Subject: Router Project To: ssampson@sabea-oc.af.mil (Steve Sampson) In your message of Mon, 27 Jun 1994 06:25:26 CDT, you write: +--------------- | implementation. If you put NOS on Linux it would be a dog compared to the | Linux I/O. FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as +------------->8 Beg pardon? JNOS/Linux writes full packets at a time (or as much as will go without blocking), and reads what's available (usually 8-10 chars in nonblock mode, up to 255 for the ALPHA.4 release's blocking mode under 1.0.x or 1.1.22+). Actually, a FOSSIL driver won't help NOS much: the "tx" process for the interface already introduces buffering to limit the impact of char-at-a-time output, the "rx" process does the same for input, and a FOSSIL driver simply separates the char-at-a-time I/O from NOS into a separate driver. Even Linux uses character-at-a-time I/O at the kernel level. The problem is the serial port hardware interface, not the software; and the fix is an intelligent port board that supports DMA. Even better, one that speaks KISS framing protocol and presents full packets with framing already handled (see next paragraph). I grant that slip_decode() is inefficient, but a FOSSIL driver still has to do char-at-a-time input to process KISS packets because of framing and escape characters. Linux does much the same to process "ICANON" mode input (think of newline as a frame delimiter and backslash as a frame escape... not to mention backspace, line kill, CR->NL conversion, etc.). A hardware KISS-framing interface that presents fully decoded packets via DMA is the only real chance to speed things up. | developed. It's frozen at about the 1991 level :-) Guess I need to switch | to Linux. What's a good internet source for the latest? +------------->8 sunsite.unc.edu:/pub/Linux/distributions (I think; can't check right now) contains several Linux distributions. At the moment, Slackware is preferred; Debian is still in development, MCC is rather minimal and requires quite a few add-ons to be usable outside its target environment as a workstation on a network, and SLS is as usual the bleeding edge that cuts both ways :-) ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org Friends don't let friends load Windows NT. Linux iBCS2 emulation ------------------------------ Date: Mon, 27 Jun 1994 19:19:55 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: Router Project To: bsa@kf8nh.wariat.org (Brandon S. Allbery) > Beg pardon? JNOS/Linux writes full packets at a time (or as much as will go > without blocking), and reads what's available (usually 8-10 chars in nonblock > mode, up to 255 for the ALPHA.4 release's blocking mode under 1.0.x or > 1.1.22+). You missed the point a little. JNOS keeps up overall.. KA9Q does not because there is so much overhead in the very low level serial code. To be quite honest compared with a top notch serial driver (which is an art form on a PC) its awful. It does loads of nasty 8086 get back into C stuff and then makes a lot of inefficient calls each character. ALan ------------------------------ Date: Tue, 28 Jun 94 01:44:28 EDT From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW) Subject: Router Project To: tcp-group@ucsd.edu >Windows (to a 14.4 modem) and it works fine. The problem is purely the NOS >implementation. If you put NOS on Linux it would be a dog compared to the >Linux I/O. FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as As many people know I've been messing with Linux here at home on packet. After all kinds of various tests what I've found is that for regular everyday packet at 9600 and 1200 bps Brandon's JNOS/Linux seems to work the best. Compared to a DOS version of JNOS, it blows them away anyday for spe. I've beaten the JNOS 1.10 series into the ground and found that the Linux version of JNOS has faster mailbox files than the 1.10 indexing code (yes it does too). Plus under the latest DOSEMU (version .52) JNOS even runs faster under that than under a regular DOS box, but it isn't stable enough for regular operation. My JNOS/Linux hasn't locked up yet (I don't believe in doing any kind of timed execution under any version of NOS either to reboot the machine. If it can't hold up on it's own then dump that version) and it's operation is better than any DOS version. I also ran the AX.25 code in the kernel and that ran good as long as there are no retries. Part of the reason for NOS is that it's designed to operate in a shared environment like amateur packet radio is. Some people forget this when they operate Windows, Unix, and other operating systems or GUI interfaces over packet. I ran a bunch of tests in my shack and over the air on packet and found that both JNOS/Linux and Linux AX.25 kernel were about the same in a controlled environment (a pair of TEKK radios and Paccomm G3RUH modems at 9600), but on packet and sharing a frequency with others and having varying round trip times running JNOS/Linux was the only way to go. I have since changed my system around so that n8fow.ampr.org is my Linux OS and roseville.ampr.org is my JNOS which is talking to the tnc's. Linux and JNOS are talking over a pty and there is a proxy arp on the JNOS for my Linux side. Linux operates slightly better now over packet by having JNOS on the front end. This is the equivalent of those people running Windows on one machine and having JNOS on another talking to the tnc's. If someone did a hack and got Windows to talk directly to a tnc without having capability of round trip timer calculation then they might be surprised at how poorly it would work (except in a point-to-point link environment). As I said before, my tests were done in house and on packet at both 1200 and 9600 baud. I'd like to hear how well 56k does though with both JNOS and Linux AX.25 kernel (or PI2). BTW, for those running a pty between JNOS and the Linux OS, if you do experience is running sluggish make sure your trace is OFF on that port (no reason to run it anyways except for debugging). My setup is running a 38400 SLIP link and a sample ftp with the trace off is: ftp> get j109lxA4.tgz 200 Type set to I. 200 PORT command successful. 150 Opening BINARY mode data connection for j109lxA4.tgz (639267 bytes). Bytes recv : 639168 RETR j109lxA4.tgz: 639267 bytes in 29 sec (21456/sec) 226 Transfer complete. ftp> With the trace on it's: ftp> get j109lxA4.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for j109lxA4.tgz (639267 bytes). Bytes recv : 639168 RETR j109lxA4.tgz: 639267 bytes in 614 sec (1040/sec) 226 Transfer complete. ftp> I know that some people have a habit of turning every feature on whether it's needed or not. This is an example of how a not needed feature (a trace on a pty during normal operation) can seriously hurt performance. Ron N8FOW ------------------------------ Date: Tue, 28 Jun 94 02:59:02 EDT From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW) Subject: Router Project To: tcp-group@ucsd.edu >Ron, I don't understand this. If you're running at 38400, then the BEST you >could do is 3,840 bytes/second. I always thought the thruput in NOS was measured in bytes/sec too. I just did an ftp from Linux to the JNOS/Linux and this is what I got: ftp> get j109lxA4.tgz 200 Port command okay 150 Opening data connection for RETR /home/ftp/pub/Linux/JNOS/j109lxA4.tgz (639267 bytes) 226 File sent OK 639267 bytes received in 25.2 secs (25 Kbytes/sec) ftp> If the pty runs faster than 38400 then heck, I'm not complaining :-) >p.s. I was also a little confused; why do you need the other JNOS talking to >the TNCs; why not have the linux/jnos talk to the TNCs directly? Actually this is what I'm doing now. I sometimes forget to distinguish between JNOS/DOS and JNOS/Linux. I've just about given up on JNOS/DOS except for Dougs 1.08dfd which I run on the hamgate. Just getting tired of chasing problems in the code and porting applications over that are already written for Unix. JNOS/Linux's main jobs are to provide a way for users to reach me (mailbox and ttylink server) and to run the TNC's. >-Mike Ron N8FOW ------------------------------ Date: Mon, 27 Jun 1994 18:19:17 -0800 (PDT) From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) Subject: TCP-Group Digest V94 #130 To: TCP-Group@ucsd.edu > > Date: Sat, 25 Jun 1994 10:34:44 -0500 (CDT) > From: ssampson@sabea-oc.af.mil (Steve Sampson) > Subject: Routing Project > To: tcp-group@ucsd.edu > > Alan Cox reports that his group is nearing completion of a Linux design > that could run in 2 Meg and a floppy. I like this idea much better, being > an advocate of using better code. For example the TCP/IP is probably no > better than Phil's, but the support code is (domain, NFS, etc). Hopefully > they will be able to release a floppy image. I put together a boot floppy image a while ago; it's a Linux 1.1 kernel, but it is not the latest release. I put it together so people could play with the Ottawa PI2 card Linux device driver. If there's demand, I can update the image to the latest, greatest kernel and ax25 code. It should be on hydra.carleton.CA in the incoming directory, or moved to a Linux/PI directory. The kernel on the floppy is compiled with WD/SMC ethernet card support, Ottaw PI2 card, the Linux ax.25 code; SLIP and NFS should be there too. If you don't have a PI card, you can still use a TNC through a serial port. Not bad for one 1.44meg boot floppy. I can't say if it will boot in only 2 megs, but it will boot in 4 megs or more. I haven't updated it because noone seemed interested. (I can update it, and it also needs a separate README, there's only so much help info I can stuff on the boot disk.) --------------------------------------------------------------------------- BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@rflab.ee.ubc.ca --------------------------------------------------------------------------- ------------------------------ End of TCP-Group Digest V94 #132 ******************************